An Introduction to Internet Information Server 4

There are several Web server programs on the market, from various vendors. Some of them are expensive; others are free. Internet Information Server 4 is Microsoft's offering in this area, and it belongs to the "free" group. In fact, it's part of the Windows NT 4 Option Pack, together with other all-important applications such as Component Services (formerly known as Transaction Server, or MTS), Microsoft Message Queue Server (MSMQ), and Microsoft Index Server. You can install the Windows NT 4 Option Pack from a Visual Studio CD or you can download it from Microsoft's Web site. All these products, in addition to other strategic softwareùsuch as Microsoft SQL Server, Microsoft Exchange Server, Microsoft Systems Management Server (SMS), Microsoft Cluster Server, and Microsoft SNA Serverùmake up the Microsoft BackOffice platform upon which you can create efficient, scalable, and robust enterprise solutions.

Even if your primary job is programming a Web site rather than administering it, you still need to have at least a basic understanding of what IIS can do. To put it simply, when you run IIS, you're transforming your Windows NT machine into a Web server that is able to accept and process requests from clients on an intranet or the Internet.

IIS 4 fully supports the HTTP 1.1 protocol, but it can also accept requests through the older and less efficient HTTP 1.0 protocol. In addition, it supports other widely accepted Internet standards, such as File Transfer Protocol (FTP) for file downloading and Simple Mail Transport Protocol (SMPT) for sending e-mail messages from within a Web application.

IIS 4 is a departure from its previous versions in that it can run as an MTS component. This has a substantial impact on its performance and robustness. In fact, a script that runs inside an ASP page can instantiate an ActiveX DLL that runs as an MTS component and still consider the DLL as an in-process component. In comparison, a script running under IIS 3 had to cross its process boundaries to access components inside MTS, and you know how slow out-of-process components are. You need MTS components to build reliable component-based transactional applications. If you care for robustness more than performance, however, you can run a Web application in a separate process. That way, if the application breaks with an error or some other malfunctioning, the other applications aren't affected.

IIS 4 includes support for multiple Web sites, and it even supports different administrators, one for each Web site. Individual Web administrators have full control of the sites they're in charge ofùthey can grant permissions, assign content rating and expiration, activate log files, and so on. But they're prevented from modifying global settings that would affect other sites hosted inside IIS, such as the Web site name or the bandwidth assigned to each Web site.

In spite of its power, IIS can be administered using a simple and user-friendly interface based on the Microsoft Management Console. You can also configure IIS to accept administrative commands through a Web-based Internet Service Manager (which lets an administrator work remotely using a regular browser), and you can even write your own applications that manipulate IIS through the COM object model that it exposes. Thanks to the tight integration between IIS and Windows NT, administrators can also manage users and groups using the system tools they're already familiar with and can use standard debug utilities such as Event Viewer and Performance Monitor.

As just mentioned, you can administer IISùas well as most other components of the BackOffice platformùthrough the Microsoft Management Console (MMC), which is shown in Figure 20-1. This utility doesn't do anything in itself; it works only as a container for one or more snap-in applications. You can install and remove snap-in applications for other programs from the Add/Remove Snap-in command in the Console menu.

Figure 20-1. The Microsoft Management Console.

The MMC utility can manage multiple computers on your LAN. Under the name of each computer in the leftmost pane, you'll find all the Web and FTP sites hosted on that computer. You can create a new site by right-clicking on a computer node and selecting the Web Site command from the New menu. A wizard starts, asking you for the site's description, its IP address and port number, the path to a directory that will act as the home directory for the site, and the access permissions for the home directory. You can leave the "(All Unassigned)" default value for the IP address during the development phase, but you should assign a different port number to each Web site defined on a given machine.

When working with a Web site, you need to account for several types of directories. The home directory is a local directory (or a directory located on another computer in the LAN) that is the entry point for the Web site when it is accessed through the Internet. For example, on my machine, the URL http://www.vb2themax.com is mapped to the directory C:\inetpub\vb2themax. All the subdirectories of the home directory can be accessed as subdirectories in the URL. For example, http://www.vb2themax.com/tips is mapped to C:\inetpub\vb2themax\tips.

A virtual directory is a directory that doesn't physically belong to the directory tree that originates under the home directory but that will appear as if it did. For example, I might have the www.vb2themax.com/buglist URL subdirectory mapped to the D:\KnowledgeBase\VbBugs physical directory. You create a virtual directory by right-clicking on a Web site node and selecting the Virtual Directory command from the New menu. The physical and virtual directories are marked with different icons in the leftmost pane of the MMC.

You can modify the properties of a Web site by right-clicking on its node and selecting the Properties menu command (or by clicking the Properties button on the toolbar). The Properties dialog box has nine tabs:

• In the Web Site tab (shown in Figure 20-2), you can modify the IP address and port number of the site, the number of allowed connections, the connection timeout (the number of seconds after which the server disconnects an inactive user), and logging settings.

  

  Figure 20-2. The Web Site tab of the Properties dialog box of an IIS Web site.

• In the Operators tab, you select which Windows NT users are granted operator privileges on this siteùin other words, who is the administrator of this site. By default, Windows NT administrators are also the Web site administrators, but this isn't a requirement.

• The Performance tab lets you fine-tune the Web site performance by tailoring it to the number of expected hits per day. In this tab, you can also enable one of the most useful features of IIS for multiple site management, bandwidth throttling, which lets you limit the bandwidth of one site so that it doesn't affect the performance of another site hosted on the same machine.

• In the ISAPI Filters tab, you select which ISAPI filters this Web site uses. You often don't need to specify any filter here because all Web sites inherit the filters defined for the computer (which you can set using the Properties dialog box of the Computer node).

• In the Home Directory tab (shown in Figure 20-3), you establish the mapping between the URL path and a physical directory on the local machine or on another machine on the LAN and the read/write permissions on the directory. In the Application Settings frame, you decide whether this directory is the starting point of a Web application.

  

  Figure 20-3. The Home Directory tab of the Properties dialog box of an IIS Web site.

  A Web application is defined as the files and the subdirectories contained in a directory marked as an application starting point. Click the Configure button to specify which ISAPI application will process files with nonstandard extensions (such the Asp.dll for managing ASP files). A Web application can optionally run as an isolated process, which means that other IIS applications and the Web server itself won't be affected if this application fails. Finally, you can set the execute permissions for the files in this directory. The options are None, Script (only scripts are allowed to execute), or Execute (scripts, DLLs, and EXEs can execute in this directory).

• The Documents tab lets you select one or more default files for the Web site's home directory. The default document is the one sent to client browsers when they access the directory without specifying a particular file. This file is typically named index.html, default.htm, or default.asp, but you can add other filenames and even set priorities for them.

• The Directory Security tab contains push buttons that let you open other dialog boxes. In the Authentication Methods secondary dialog box, you decide whether clients can log in to this Web site using anonymous access, a basic authentication method based on user names and passwords (which are sent as plain text); or the Windows NT Challenge/Response method, in which access is restricted using Windows NT File System's Access Control Lists and information is exchanged in encrypted form.

  In the IP Address And Domain Name Restriction secondary dialog box, you select which computers are granted or denied access to this Web site. When publishing a Web site, you obviously have to grant access to anyone. But you can enforce stricter access permissions for selected portions of the site. All the settings in this tab are inherited from the properties of the parent computer node.

• The HTTP Headers tab lets you set an expiration date or interval for the documents in the Web site. This setting is crucial because it tells the client browser whether it can reuse the information in its local cache, thereby reducing download times dramatically.

• The Custom Errors tab lets you specify which page of your server the client browser is redirected to when an HTTP error occurs. You don't usually need to alter the settings in this tab, unless you want to override the default action or localize the error message to a different language.

You can modify the properties of a physical or a virtual directory by right-clicking on the corresponding node in either pane of the MMC and selecting the Properties menu command. The Properties dialog box contains a subset of the tabs that are found in the Web site's Properties dialog box. For this reason, I won't describe them again. The same thing happens with the Properties dialog box of individual document files.

Just to remind you, IIS lets you define the behavior and the attributes of each individual element in the computer/site/directory/file hierarchy. At the same time, it saves you a lot of time by automatically assigning to an object all the attributes of its parent. The tabs in the Properties dialog boxes for these elements are identical, and the user interface is logical and coherent.

To browse the pages hosted in a Web site, you must activate the site first, either by clicking on it and selecting the Start command from its context menu or by clicking on the Start Item button on the toolbar. You can also stop or pause a Web site using other menu commands or toolbar buttons.

To see how a page will appear in a client's browser, right-click on an HTM or an ASP document in the rightmost pane and select the Browse menu command. Browsing a page from within the MMC rather than directly from within Windows Explorer might deliver completely different results, because if the page contains server-side scripts they will be executed correctly. This approach permits you to test your ASP programs on the same machine you're developing them.

The context menu that appears when you right-click a file also contains an Open command, which loads the file into the application that has registered itself as the default HTML editor. For example, if you have Microsoft InterDev installed, this command will load the HTM or the ASP file into InterDev for editing.

In a nutshell, an ASP page is a document that resides on the Web server and that contains a mixture of HTML code and server-side scripts. Such scripts process requests coming from client browsers and can build a response page for that particular client, for example, by querying a database through ADO. This capability is very important, because it lets you create "dynamic" HTML pages that can be downloaded by any browser that supports plain HTML. For this reason, ASP can play a key role in Internet applications, whereas DHTML should be used only in more controlled environmentsùsuch as a company intranetùin which all clients can standardize on Internet Explorer.

Don't let the adjective "dynamic" confuse you. We're not talking about dynamic pages in the DHTML sense. The ASP technology doesn't deliver pages with animation and transition effects. Rather, with it you can create pages on the fly that are customized for each individual client. For example, you can have the server accept a request from a client, perform a query on a database, and then return the results of the query as a standard HTML table to that particular client.

An HTML page can contain two types of scripts: server-side scripts, which are executed on the server and contribute to creating the HTML document sent back to the browser, and client-side scripts, such as VBScript or JScript procedures executed within the client browser. The two types of scripts require different tags in an ASP page because the ASP filtering mechanism must execute server-side scripts without sending them to the browser but has to send client-side scripts to the browser without interpreting them.

You can insert a server-side script inside an ASP page in two ways. The first way is to use the <SCRIPT> tag with the RUNAT attribute, as here:

<SCRIPT LANGUAGE="VBScript" RUNAT="Server"> ' Add server-side VBScript code here. </SCRIPT>

You can specify either VBScript or JScript in the LANGUAGE attribute. Unlike client-side scripts, however, the default script language for ASP is VBScript, so you can safely omit the language specification. The second way to insert server-side scripts is to use the <% and %> delimiters. For example, the following statement assigns the current server time to the currTime variable:

<% currTime = Now() %>

I won't show ASP examples written in JScript, but for the sake of completeness, I'll show you how you can change the default script language for all server-side script fragments enclosed in the <% and %> delimiters:

<%@ LANGUAGE = JScript %>

Two types of statements can be enclosed between the script delimiters: those that execute a command and those that return a value. For statements that return a value, you must insert an equal sign (= character) immediately after the opening delimiter, as here:

<% = Now() %>

(Note that you can insert comments in statements that execute a command, but not in those that return a value.) The value returned by the VBScript expression is inserted in the HTML page exactly where the code snippet is. This means that you can (and often do) mix plain HTML text and server-side script code in the same line. For example, here is the source for a complete ASP document that displays the current date and time on the server:

<HTML> <HEAD><TITLE>Your first ASP document</TITLE></HEAD> <BODY> <H1>Welcome to the XYZ Web server</H1> Today is <% = FormatDateTime(Now, 1) %>. <P> Current time on this server is <% = FormatDateTime(Now, 3) %>. </BODY> </HTML>

You can use the <SCRIPT> tag to enclose individual statements and entire routines:

<SCRIPT RUNAT="Server"> Function RunTheDice() RunTheDice = Int(Rnd * 6) + 1 End Function </SCRIPT>

The routine defined in the page can be called elsewhere in the script:

<% Randomize Timer %> First die shown <% = RunTheDice %> <P> Second die shown <% = RunTheDice %>

You can also embed a VBScript statement within <% and %> delimiters, but without the = symbol. The following example is more complex than the previous ones in that it alternates plain HTML and server-side statements:

<% h = Hour(Now) If h <= 6 Or h >= 22 Then %> Good Night <% ElseIf h <= 12 Then %> Good Morning <% ElseIf h <= 18 Then %> Good Afternoon <% Else %> Good Evening <% End If %>

Server-side scripting isn't a lot different from client-side scripting, at least syntactically. The real difficulty in writing ASP code is in trying to anticipate what your script produces when IIS executes it.

The only relevant difference between regular VBScript code and server-side VBScript code is that a few statements are prohibited in the latter, most notably those statements that show a dialog box on the screen. This prohibition is understandable, though. After all, the script will be executed on an unattended server; no one will be there to click the OK button in a message box. So just stay clear of the MsgBox and InputBox statements when you're writing server-side VBScript code.

Server-side scripts support include files, that is, files that reside on the server and that are included as-is in the HTML page being generated. This is the syntax for inserting an include file:

<!-- #include file="Routines.inc " -->

The filename can be either a physical path (such as C:\Vbs\Routines.inc) and in this case can be absolute or relative to the current file, or it can be virtual, but in this case you need a slightly different syntax:

<!-- #include virtual="/Includes/Routines.inc" -->

There's no restriction on the file's extension, but it's common practice to use the .inc extension, to differentiate these files from other files on the Web site. The include file can contain virtually anything: plain text, HTML code, server-side scripts, and so on. The only restriction is that it can't contain incomplete portions of scripts, such as an opening <SCRIPT> tag without the corresponding </SCRIPT> tag.

A typical use for include files is to make a number of constants available to your ASP scripts. But if these constants come from a type library, as all the ADO constants do, there's a better way to work: Just include the following directive at the very beginning of a page or in the Global.asa file. (For more information about this file, see the "The Global.asa file" section, later in this chapter.)

<!--METADATA TYPE="typelib" FILE="c:\program files\common files\system\ado\msado15.dll" -->

If ASP pages were only able to run server-side scripts written in VBScript or JScript, they would hardly qualify as a viable means for writing complex Internet applications. Fortunately, you can augment the power of plain VBScript by instantiating external ActiveX components, either standard or custom ones. For example, a server-side script can query a database by instantiating an ADO Recordset object and then using its properties and methods. To create ActiveX components, you have to use the Server.CreateObject method instead of the simpler CreateObject command, but apart from this detail, you can process the returned object reference as you would in plain VBScript (or Visual Basic, for that matter). The following ASP code snippet demonstrates how you can use this capability to dynamically build a table with the results of a query on the Authors table of a copy of the Biblio.mdb database stored on the server machine:

<% Dim rs, conn, sql Set rs = Server.CreateObject("ADODB.Recordset") ' Modify the next lines to match your directory structure. conn = "Provider=Microsoft.Jet.OLEDB.3.51;" conn = conn & "Data Source=c:\Microsoft Visual Studio\Vb98\Biblio.MDB" ' Return all the authors whose birth year is known. sql = "SELECT * FROM Authors WHERE NOT ISNULL([Year Born])" rs.Open sql, conn %> <H1>A query on the Authors Table</H1> <TABLE WIDTH=75% BGCOLOR=LightGoldenrodYellow BORDER=1 CELLSPACING=1 CELLPADDING=1> <TR> <TH ALIGN=center>Author ID</TH> <TH>Name</TH> <TH ALIGN=Center>Year Born</TH> </TR> <% Do Until rs.EOF %> <TR> <TD ALIGN=center> <%= rs("Au_Id")%> </TD> <TD> <%= rs("Author")%> </TD> <TD ALIGN=center> <%= rs("Year Born") %> </TD> </TR> <% rs.MoveNext Loop rs.Close %> </TABLE>

The result of this ASP code is shown in Figure 20-4. An important point is that the browser on the client receives a plain HTML table and doesn't see a single line of server-side script code. Unlike client-side scripts, no one can peek at the code that makes your application work.

Figure 20-4. You can process a database query on the server and send the results as a pure HTML table to the client browser.